1. Field of the Invention
The invention generally relates to an availability engine for a hotel central reservation system (HCRS), a car rental (CRS) central reservation system, and/or an airline (CRS) central reservation system. More particularly, the invention relates to an availability engine that is configured to exchange hotel availability rates and inventory (ARI) messages with the property management systems (PMSs) of hotels. The invention also relates to a method of providing availability information gathered from property management systems (PMSs) and responding to requests for area or hotel availability received from a multitude of internal and external sources.
2. Background
Prospective travelers pose a basic question of hotels and hotel groups: are rooms available and if so at what rate? Multiple variations of this question are posed to hotels and their respective reservation systems through various channels more than a billion times a day. The available room part of the question is a simple yes or no, perhaps enhanced with specific room types that may be available, but the exact or total inventory at a hotel is not needed to answer the question.
The rate question is more complicated since it may depend on the number of guests or special rates requested, and these in turn depend on the way the hotel reservations system represents each individual property. In the past, hotel rates and room types have tended to be standardized in order to respond to the variety of external distribution channels posing availability questions.
Today, however, individual hotels are increasingly managing their rooms and rates as unique to each hotel. This is the direct result of distributed ownership interests in individual hotels, ranging from franchise owners to property management groups that may own many hotels across a number of brands. The design and implementation of current hotel central reservation systems (HCRSs) cannot readily support this change without making large changes to the existing systems and infrastructure.
Hotel chains have long employed central reservations management systems to link individual properties to external sources of demand for hotel rooms. The external sources include individual callers to a chain reservation call center, travel agents connected to airline global distribution systems, and individuals using proprietary chain or online travel websites such as Expedia or Hotels.com.
In the late 1960s, Holiday Inns became the first hotel chain to implement a Hotel Central Reservation System (HCRS) using a version of an existing airline reservation system. Other chains followed suit in the 1970s and 1980s with Marriott, Hyatt, Sheraton and others employing the same basic airline systems technology.
At first, the central systems were used to serve reservation agents in call centers dedicated to each chain. Fax or Teletype messaging updated hotel inventory and rate availability, later replaced with online terminals connecting hotel staff to the central system.
During the 1980s, the major hotel chains began installing Property Management Systems (PMS) in the majority of their properties. They also installed telecommunications networks linking the hotels to the HCRS, allowing for direct, timely and accurate delivery of reservations taken through the HCRS. The HCRSs employed by major chains range in age from 10 years (Hilton) to 20 years (Hyatt) to 30 years (Marriott) to 40 years (Holiday, now part of Intercontinental Hotel Group).
Further refinements to HCRSs in the 1970s and 1980s added direct connections to travel agents through their connections to Airline Reservation Systems, replacing Teletype delivery of reservations. By 1990 most travel agents and agencies had established connections with the airlines as a servicer, which in turn gave the travel agents easy and direct access to hotel information and reservations. For instance, by 1990 the Sabre system from American Airlines had about 30,000 travel agents connected through their system. Sabre was in turn connected directly with most major hotel chains. In addition to Sabre, Apollo (United), WorldSpan (TWA), Amadeus and other Global Distribution Systems (GDS) covered most travel agents around the world.
The HCRSs all provided a common service to external sources through the GDSs: they could respond to requests for information about hotel availability and rates from multiple channels of distribution.
The standardization was needed to provide consistent responses to external sources, ranging from individual callers to chain reservation centers to travel agents connecting through Global Distribution Systems like Sabre (American Airlines), Apollo (United) and many others. This was a compromise, overcome in large part by enforcing standards on individual hotels about the kinds of room types they could offer for sale, and the rates and packages available.
Some workarounds have been implemented that allow individual properties to sell non-standard room types but, in general, requests from external channels for hotel availability of rates and inventory, called ARI as a term of art in the industry, used standard room types and rate terminology. ARI more generally refers to the availability of room types and rate plans, called products. This broader meaning is used herein.
Until the mid 1990s, access to hotel availability was limited to travel agents connected to airline systems like Sabre, or by calling a chain reservation center. Starting in 1996 with the creation of Travelocity, then a part of the Sabre system, a number of online travel agencies (OTAs) began providing individual travellers with direct access to hotel and airline information through the Internet. Today there are dozens of OTAs worldwide, all trying to gain access to and serve the individual traveller. Expedia, Kayak, Travelocity, Hipmunk and many others now compete with travel agents for the commissions that come from booking travel with airlines and hotels.
However, this explosive growth in OTAs has created an equally explosive growth in ARI requests to HCRSs. In the last three years, the number of ARI requests has gone up by 3 to 5 times or more, with minimal growth in the total number of reservations from all sources. A typical HCRS can receive hundreds of requests for availability information for every confirmed booking. Growth in the number of distribution channels is expected to continue, with corresponding growth in the load placed on HCRSs by availability requests.
To respond to this demand, hotel chains have added capacity to their HCRSs, created some shortcut methods, employed newer database technology, and redesigned parts of their system in an attempt to let their existing technology meet the demand. The net effect has been an unbalanced approach that puts extreme demands on systems, software and database technology beyond what was ever considered in original designs.
3. Limitations of Current Hotel Central Reservation Systems
A basic assumption in virtually all HCRS systems is that the central system is the authoritative source for information, not the local property system. The justification for this approach is that the ARI requests come to the HCRS, and bookings are made and confirmed by the HCRS, so the HCRS must have the most up-to-date information in order to answer the ARI request and confirm the booking.
The fundamental HCRS design assumption is that PMSs would not be able to manage communications with multiple external distribution channels, and that it is systematically easier to manage those communications through a central system. A further assumption was that the HCRS therefore needed to be the authoritative source, and moreover had to be the definitive source for ARI. The HCRS has to be authoritative in responding to requests for availability information, but it does not have to manage and control all ARI information, as will be described with regard to invention hereinafter, and it also does not have to lose the granularity and specificity with respect to what each individual property may have to offer through its PMS.
Current HCRS implementations use database technology, either a simple data-store or a Relational Database Management System (RDBMS), to manage information required to calculate area and hotel availability requires multiple data access operations to obtain hotel details and availability of rates and room types. Current HCRSs are based on the assumption that direct memory access to ARI was not possible given the available memory sizes in servers. Typical area availability search can require 100s to 1000s of database accesses, resulting in area availability response times in 1 second to 10 second range or more.
Also, current HCRS implementations emulate or duplicate the inventory methods and controls in PMSs, with relatively fixed room types and rate plans. In order to synchronize information between the two systems, HCRS and PMS, chains usually employ a full two-way interface (term of art) that constantly exchanges information between the two systems on rate and room availability. The “full two way interface” in HCRSs is designed to provide an exact copy of PMS information to be used for area and hotel availability. This avoids having the PMS satisfy all availability requests, at the expense of managing duplicate information across multiple hotels. In practice, the full two-way interface amounts to exchanging new, changed or cancelled bookings between the systems, and accepting updated room and rate information from the PMS if it manages rooms and rates. Many chains even force all reservations processing and product maintenance to be managed by the HCRS, even for hotel reservation agents, in order to ensure consistent responses to all channels and to prospective guests.
The conventional HCRS implementations manage all combinations of room types and rate categories, along with overriding limits for room type, rate category and total hotel availability. Moreover, the conventional HCRS systems generate availability responses as part of the HCRS application, along with managing bookings, availability, rates, inventory, room types, etc. Conventional HCRS implementations employ a complex, database intensive structure for rate plans, and have a fixed time horizon for ARI information, usually 400 days or less.
This approach had advantages given the technology available when they were first developed: it reduced the load on relatively small PMSs installed at individual hotels and eliminated the potential communications load between hotel PMSs and external channels by answering ARI and booking requests from the HCRS, while generally ensuring consistent information in both systems.
Given technology available today, the limitations imposed by this approach are significant. The PMS is essentially slaved to the HCRS, with little ability to represent unique or singular advantages of the local hotel room types. The communications load on both systems is still significant, often requiring updates multiple times each hour. The unique room types at a hotel are homogenized for the GDSs and OTAs by converting them to standard room types, and special rates and packages are also often limited to standard types.
The HCRS design and implementation has to be continually optimized to try to provide sub-second response to an ever-growing number of external sources. Even though some chains have HCRSs originally built decades ago, they have been continually refined and updated with newer technologies to adapt to larger chain size and the demands of external reservation sources. Building and maintaining a new HCRS is now assumed to be a $50 million project at a minimum, based on industry articles about current, previous and failed HCRS development and upgrade projects.
In most HCRSs, the hardware component dedicated to interfacing with external channels and PMSs for ARI information is more than 50% of total required capacity. The portion of the development and maintenance cost for the software and database required to support the current PMS/external channel interface is 25% to 50% of total costs. Based on industry publications on HCRS operating costs for hardware and software, these are multi-million dollar costs for each chain.
An informal survey of some major hotel chain reservation systems in January 2013 showed that the time to perform an area availability search (looking for rooms at all hotels in a city or area) for a multi-week stay ranged from a few seconds to more than 15 seconds. Area searches make up a significant portion of the requests handled by HCRSs, and a proportionately larger part of their total computing capacity. A new approach is needed to provide near-instantaneous response, while reducing hardware and software complexity and expense.